Evolution of HTTP

Learn about different versions of HTTP, their features, and shortcomings.

Introduction#

HTTP is a widely used protocol, which directs the communication between clients and servers. This protocol was proposed and developed by Tim Berners-Lee in 1991. Over the years, this protocol has undergone many modifications that have made it feature-rich, flexible, and simple. In this lesson, we’ll compare different HTTP versions that enable us to choose a specific version for designing an API for a particular service. We discuss the following HTTP versions in the table below.

Version

Release Year

HTTP/0.9

1991

HTTP/1.0

1996

HTTP/1.1

1997

HTTP/2.0

2015

HTTP/3.0

2019

HTTP/0.9#

HTTP/0.9 was the initial version of HTTP. It was the simplest client-server and request-response protocol. This version of HTTP only had the support of the GET request method, and similarly, the response would consist of hypertext only. This version had no support for HTTP headers; as a result, this version couldn't transfer other content-type files. The connection would also terminate immediately after sending the response.

HTTP/1.0#

HTTP/1.0 was a browser-friendly protocol that supported HTTP header fields—including rich metadata—for requests and responses. As a result, the response was not limited to just hypertext, but could transfer other types of files, such as scripts, stylesheets, and media. HTTP/1.0 brought a number of changes to its infant version of HTTP/0.9. The HTTP/0.9 version's specification was about a page long; however, the HTTP/1.0 RFC came in at 60 pages. In comparison to HTTP/0.9, HTTP/1.0 had the support of three HTTP methods: HEAD, GET, and POST. Apart from the support of various HTTP methods, HTTP/1.0 used some ideas that we’re familiar with, for example, headers, response status codes, errors, redirection, conditional requests, and encoding.

The drawbacks of HTTP/1.0#

In HTTP/1.0, the notable flaws highlighted below had to be addressed:

  • Non-persistent: An issue with HTTP/1.0 is its inability to keep the connection open between requests. The TCP connection would terminate after the client received the response to a single HTTP request. This approach is called non-persistent HTTP and it worked well in a world when a web page was typically just HTML text. The number of embedded links for resources like icons and other media content has increased significantly over time on the average web page. Non-persistence adds latency for the client, and in our world, many use cases need little to no latency for a better user experience. Let's understand this issue in detail, as given below.The following illustration shows the TCP three-way handshake required before the HTTP request is made. If a connection establishes and terminates after a request, the three-way handshake is repeated before making the next request. Therefore, HTTP/1.0 was not an efficient protocol for subsequent requests.

Server
Server
Client
Client
Three-way handshake
Three-way h...
TCP connection opened
TCP connection opened
TCP connection closed
TCP connection closed
HTTP request
HTTP request
HTTP response
HTTP response
Time
Time
Three-way handshake
Three-way han...
. . .
. . .
Single HTTP request
Single HTTP req...
Viewer does not support full SVG 1.1
A three-way TCP connection establishment in HTTP/1.0 before each request
  • Lack of host header: HTTP/1.0 had no mandatory host header in the request message. The host header identifies the target domain name to whom the request is made. If more than one website is hosted on the same server (virtual hosting), this header enables the server to identify the website easily.

  • Limited caching headers: HTTP/1.0 performs cache revalidation using the If-Modified-Since header.

HTTP/1.1#

HTTP/1.1 came with a tremendous amount of features and options that overcame the drawbacks of the previous versions—HTTP/0.9 and HTTP/1.0. Due to the flaws mentioned above, there was a need for a major revision in HTTP/1.0. In this regard, HTTP/1.1 was proposed, which came with many features that are defined in RFC 2616. The following notable changes are made to the HTTP/1.1 to overcome the drawbacks of the HTTP/1.0 protocol.

  • Persistent connection: Unlike HTTP/1.0, HTTP/1.1 now enables persistent connection. In HTTP/1.1, we may create a TCP connection, submit a request, receive a response, and then send more requests, all while receiving more responses. Another name for this strategy is connection reuse. The relative overhead caused by TCP is decreased per request by spreading out the setup cost, startup, and release over many requests.
    The process of connection reuse is demonstrated in the following figure:

A persistent connection supported by HTTP/1.1
A persistent connection supported by HTTP/1.1
  • Pipelining: It’s also possible to pipeline requests, which enables sending multiple (inflight) requests before the arrival of the responses of earlier requests. This approach decreases the client's perceived latency and increases the system's performance.

Server
Server
Client
Client
HTTP request
HTTP request
HTTP response
HTTP response
. . .
. . .
Server
Server
Client
Client
Multiple HTTP requests
Multiple HTTP requests
HTTP request
HTTP request
HTTP request
HTTP request
HTTP response
HTTP response
HTTP response
HTTP response
Multiple HTTP responses
Multiple HTTP responses
Without pipelining
Without pipelining
Pipelining
Pipelining
. . .
. . .
Viewer does not support full SVG 1.1
Client's interaction with the server with and without pipelining

  • More HTTP methods: HTTP/1.1 is the most commonly used version that supports multiple HTTP methods, including HEAD, GET, POST, PUT, DELETE, TRACE, and OPTIONS .

  • The Host header: HTTP/1.1 has made the Host header mandatory, which is included by default in the request.

  • Virtual hosting: Virtual hosting enables a web server to host multiple websites using a single web server. It wasn't available in HTTP/1.0 because the marketplace would be simpler with static web pages. But as the demand to economically serve many websites from a single server grew, HTTP/1.1 added the needed support. This feature is now provided in HTTP/1.1 via the Host HTTP header, allowing the server to determine the website a request is intended for.
    The advantage of virtual hosting is that it enables web hosting companies to offer services at a lower cost by hosting multiple websites on a single server.

  • The Upgrade header: HTTP/1.1 has the ability to upgrade the already established client-server connection to a new protocol via the Upgrade header. For example, the protocol can be upgraded to HTTP/2.0 or HTTPS after making a connection with the server.

  • Transfer-Encoding: HTTP/1.1 provides a way to send specific commands to any proxies between the client and the server via a mechanism called transfer encoding. However, we won’t be relying on it in this course because this mechanism can be taken advantage of by a malicious or buggy proxy and can make debugging of any occurring issues difficult.

  • Additional cache headers: HTTP/1.1 has advanced headers to control cache revalidation.

HTTP/2.0#

The Web has used HTTP/0.9 and HTTP/1.0 from the beginning; however, HTTP/1.1 was developed in 2007 and became a little outdated in terms of its services by 2012. Therefore, IETF established a working group to develop HTTP/2.0. The starting point was a technology called SPDY that Google had developed before. In May 2015, the finished product was released as RFC 7540.

Mike Belshe and Roberto Peon (software engineers at Google) suggested SPDY (pronounced “speedy”) in 2009 as a replacement for HTTP. It was a successful project demonstrating that there’s a lot of room for performance improvement for HTTP. Before SPDY, it was believed that the industry lacked the desire to make breaking or incompatible modifications to HTTP/1.1. The reason behind this concept was that the modification would require a lot of effort to align and incorporate changes between browsers, servers, proxies, and other entities.

However, SPDY soon demonstrated a need for something more effective and a readiness to adapt. It laid the foundation for HTTP/2.0, demonstrating some of SPDY’s essential capabilities, including multiplexing, framing, and header compression.

SPDY was adopted by gradually introducing it into existing web protocols and standards. This allowed for a smooth transition from existing protocols to SPDY—without breaking anything. For example, SPDY was designed to be compatible with the existing HTTP/1.1 protocol so that existing web applications could be used with SPDY without any changes. Additionally, it was designed to be backward compatible with existing web browsers, so users could continue accessing websites without disruption.

The primary focus of HTTP/2.0 was to maintain backward compatibility; therefore, the headers, URLs, and general semantics didn't change much. Any new application could use HTTP/2.0 to benefit from the latest features, while the existing applications could still operate on HTTP/2.0 using limited features because of backward compatibility. The main features of HTTP/2.0 are the following:

  • Prioritized responses: In the older HTTP/1.1, multiple requests over a TCP connection are sent in a pipeline where the responses from the server are received in the order the requests were sent. On the other side, in HTTP/2.0, many requests can be sent, and the server responds in any order based on the priorities of the requests. For example, if there are requests for two different images, the server sends the small image first. When the browser starts displaying the small image, the second image is sent to the client. This feature of HTTP/2.0 is called multiplexing, in which the responses can arrive in any order.

  • Server push: In HTTP/2.0, a server can send resources to the client that might be needed on the client-side prior to the client's request for the resources. This mechanism is called a server push. For example, if a client requests a web page and the server knows that it needs other resources, such as style sheets and script files, the server sends these resources prior to the request from the client.

Points to Ponder

Question 2

What is the difference between HTTP pipelining and multiplexing?

Hide Answer

There’s a subtle difference between HTTP pipelining and multiplexing, that is, the order of arrival of responses.

Pipelining: In pipelining, multiple HTTP requests over a single TCP connection can be made without waiting for the earlier request’s responses. The responses arrive in order.

Multiplexing: On the other hand, in multiplexing, we can make multiple requests over the same TCP connection without waiting for the earlier requests’ responses. The responses arrive in any order.

2 of 2

HTTP/3.0#

HTTP/3.0 was a major revision in HTTP that was created by complementing the commonly used HTTP/1.1 and HTTP/2.0. The primary difference between HTTP/2.0 and HTTP/3.0 is the transport protocol that is used to support HTTP messages. The previous version relied on the Transmission Control Protocol (TCP). However, HTTP/3.0 utilizes QUIC (Quick UDP Internet Connections) on top of User Datagram Protocol (UDP). The main features of HTTP/3.0 are:

  • Adoption of QUIC protocol: Multiplexing of streams and per-stream flow control is provided by QUIC, a transport protocol. It has the capacity to enhance HTTP performance in comparison to TCP mapping by offering stream-level reliability and congestion control throughout the connection.

  • TLS 1.3: HTTP/3.0 also implements TLS 1.3 at the transport layer, providing similar security and integrity to running TLS over TCP.

  • Improved performance: HTTP/3.0 has lower latency and high reliability due to the adoption of the QUIC protocol. In some studies, HTTP/3.0 is faster than HTTP/2.0.

  • Avoids head-of-line blocking: It also addresses a major problem in HTTP/1.1 and HTTP/2.0, known as head-of-line blocking.

The following figure shows the HTTP/3.0 protocol stack:

HTTP/3.0 protocol stack in comparison to HTTP/1.1 and HTTP/2.0
HTTP/3.0 protocol stack in comparison to HTTP/1.1 and HTTP/2.0

The following table summarizes the differences between different versions of HTTP:

Comparison of Different Versions of HTTP

Version

Methods Supported

Support for Headers

Connection Nature

Other


HTTP/0.9

GET


No

Terminates immediately after the response

  • Only supports hypertext


HTTP/1.0

HEAD, GET, POST


Yes

Terminates immediately after the response

  • Supports hypertext, hypermedia and other files, such as scripts




HTTP/1.1

HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS




Yes




Persistent

  • Extended HTTP methods
  • Pipelining
  • Encoding
  • Virtual hosting
  • Upgrade header
  • Cache headers




HTTP/2.0

HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS



Yes



Persistent

  • Backward compatibility: Flexibility to choose any version of the HTTP for communication.
  • Multiplexing
  • Headers compression (reduces latency and optimizes bandwidth)



HTTP/3.0

HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS



Yes



Persistent

  • Instead of relying on TCP, it utilizes QUIC on top of UDP
  • Solves the major problem known as head-on-line blocking
  • 3x faster than HTTP/1.1

Summary#

In this lesson, we discussed various versions of the HTTP protocol, including HTTP/0.9, 1.0, 1.1, 2.0, and 3.0. We presented the pros and cons of each protocol that will help us select a specific HTTP version for a particular service in the upcoming chapters.

Hypertext Transfer Protocol (HTTP)

Remote Procedure Calls (RPCs)